Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debug Renderer API #230

Draft
wants to merge 7 commits into
base: 1.19
Choose a base branch
from
Draft

Conversation

williambl
Copy link
Contributor

@williambl williambl commented Dec 8, 2022

This is an API for Debug Renderers (DebugRenderer)

Motivation

Vanilla provides a few Debug Renderers, ~all of which are disabled:

  • pathfinding viewer
  • water debug
  • chunk borders
  • heightmap viewer
  • brain debug
  • etc.

The DebugRenderer class provides various utility methods, and custom Debug Renderers can be created by implementing DebugRenderer.Renderer.

I've been using this occasionally in fabric mods, just by bridging the SimpleDebugRenderer to a WorldRenderEvents.Last and then conditionally registering that depending on a public static final boolean. This isn't ideal. In addition, turning on the vanilla Debug Renderers has to be done either with mixins or manually running them in a render event.

Many vanilla Debug Renderers require extra data to be sent by the server: these are sent through custom payload packets (see the IDs in CustomPayloadS2CPacket which start with minecraft:debug/). These are sent in various static methods in DebugInfoSender. However, most of these methods have their contents stripped out.

Content

Therefore I am making a Debug Renderer API, which adds the following:

  • DebugFeature class, with methods:
Identifier id();
// whether it needs to be enabled on the server in order to render on client
boolean needsServer();
// is enabled locally
boolean isEnabled();
// used on server
boolean isEnabledOnServerAndClient(ServerPlayerEntity player);
@ClientOnly
boolean isEnabledOnServerAndClient();
@ClientOnly
boolean shouldRender();
  • Debug Feature registry/factory (common-side), to which IDs can be added (+ a boolean which determines if it needs to be enabled on both client and server to render), and it creates a DebugFeature. (DebugFeature myDebugFeature = DebugFeatureRegistry.register(new Identifier("my_mod:test"), true))
  • Debug Renderer registry (DebugRendererRegistry.register(myDebugFeature, MyDebugRenderer::new))
  • Debug Features are enabled/disabled individually with a command /debug enable x:x, and on client with a client command /debug_client enable x:x
  • Debug Renderers only run if the corresponding Feature is enabled (and, if the feature requires that it is enabled on the server too, it checks that)
  • We register Debug Features for each of the vanilla Debug Renderers
  • We re-implement the missing methods in DebugInfoSender, checking that the corresponding Debug Feature is active on server and only sending the packets to clients with it also active

@williambl williambl changed the base branch from 1.19.3 to 1.19 December 8, 2022 18:16
@williambl
Copy link
Contributor Author

Some vanilla debug renderers enabled with this API:

2022-12-08_23 41 01
2022-12-08_23 22 39
2022-12-08_23 22 27

@williambl
Copy link
Contributor Author

Other than re-implementing some missing MC methods, this is now fully functional.

@EnnuiL EnnuiL added t: new api This adds a new API. s: wip This pull request is being worked on. library: misc Related to the misc library. labels Apr 18, 2023
@Redfan2
Copy link

Redfan2 commented Aug 24, 2024

What is the state of this?

@OroArmor
Copy link
Member

Definitely stalled, but I was looking into it recently and it seems fairly interesting and not too bad to update

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
library: misc Related to the misc library. s: wip This pull request is being worked on. t: new api This adds a new API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants